Sistema Web » Virtual Hosts

Los Virtual Host son los Elementos dentro del Sistema Web de Cloud-Bricks, que permiten conectar las peticiones Web recibidas por el Cloud con los servidores HTTP que atenderán dichas peticiones. El Virtual Host decide hacia qué servidor direccionar las peticiones basado en el dominio del site que está siendo solicitado.

Conceptos básicos de Virtual Host

Para poder entender como funciona y como configurar un Virtual Host hay varios conceptos relacionados que debemos aprender.

Dominios

Los dominios son los nombres utilizados en Internet para identificar redes de organizaciones. Por ejemplo, cloud-bricks.net o google.com

Los web sites que configuraremos pueden estar asociados a uno o varios dominios.

Protocolo HTTP/HTTPS

HTTP es el protocolo de comunicación que permite que un navegador converse con un Servidor Web para intercambiar datos. HTTPS agrega una capa de seguridad en la comunicación, permitiendo la encripción de los datos mediante TLS/SSL. Para configurar un virtual Host con HTTPS, se debe primero  configurar un certificado digital.

Locations

Los locations son elementos que permiten dividir un Web Site en zonas o carpetas distintas cada una con configuraciones independientes.

Desde un location es posible configurar restricciones de acceso, indicar qué Servidor de HTTP debe gestionar el contenido, generar redirecciones y controlar el cache.

Los locations pueden restringir el acceso utilizando las direcciones IP configuradas en la lista de Máquinas y Redes del Firewall.

Los locations permiten activar y configurar el mecanismo de Web Cache.

Los locations también gestionan el destino de los request, de esta manera  es posible dirigir las solicitudes de un dominio a un servidor HTTP especifico o realizar un redirect hacia un URL externo. Cuando se  solicita configurar un redirect, aparece el campo de destino: aquí se ingresa el url hacia donde queremos redireccionar al usuario.

Si en lugar de un redirect elegimos que el contenido del Location debe ser gestionado por Servidor HTTP, aparece el campo de timeout donde se ingresa el tiempo máximo que el Cloud esperará para obtener una respuesta del servidor virtual.

Configuración de Cache en Locations

Cuando dentro de un Location se activa la opción de cache HTTP se habilitan dos opciones más, las cuales funcionan de acuerdo a las cabeceras de cache que posea la aplicación.Ver más información sobre el sistema de caché.

• Cache expirado (Stale Cache): Si el proxy reverso tiene en memoria una copia ya expirada de una página (es decir que su tiempo de caché ya venció) y por algún motivo no es posible obtener una copia actualizada (Ejemplo: el web server se cayó), entonces autorizamos al proxy a entregar la copia "vieja" al cliente que la solicite. De esta manera podemos entregar una copia vieja en lugar de no poder entregar nada o generar un error.
• Cookie no cache: Esta opción es especialmente útil cuando el portal web usa un sistema de autenticación, y mediante una cookie específica indica que el contenido que se genere durante la sesión no debe almacenarse en el caché. Al activar esta opción aparece el campo para ingresar el nombre de la cookie.

Redirect HTTP 

Los redirect HTTP son opciones para redirigir el tráfico a sitios externos. El redirect puede ser útil por ejemplo se hace mantenimiento de un portal web y todo el tráfico se redirige a un portal distinto. La opción de redirect se encuentra en el campo de "Destino" dentro de los locations. Es posible escoger entre dos tipos de redirect:

• Redirect 301 (Permanente): Este redirect indica que el host ha sido capaz de comunicarse con el servidor pero el archivo solicitado ha sido movido a otra dirección permanentemente.
  
• Redirect 302 (Temporal): Este redirect indica que el host ha sido capaz de comunicarse con el servidor pero el archivo solicitado ha sido movido a otra dirección temporalmente.
  

Configurar un nuevo Virtual Host

Los Virtual Hosts pueden administrarse a través de la opción Web System -> Virtual Hosts. del menú izquierdo.
Para que un sitio web sea visible en Internet es necesario crear un virtual host y configurar en él los dominios asociados.

1. Nombre del virtual host, no pueden existir dos nombres iguales.
2. Protocolo web del sitio.
• HTTP: Protocolo para sitios Web normales, sin seguridad.
• HTTPS: Protocolo web seguro, utiliza la capa de seguridad SSL. Para mayor información ir a la sección Certificados SSL.
  
• HTTP & HTTPS: Permite que su web site pueda ser acessado tanto de manera segura (HTTPS) como insegura (HTTP)
  
3. Botón de agregar dominios: Es posible configurar varios dominios en un único virtual Host.
   
4. Nombre de dominio: Aquí se pueden agregar todos los dominios que hayan sido comprados y que estén apuntando hacia el Cloud.
   También podemos poner el nombre del dominio del sistema por defecto el cual tiene el formato nombreMaquinaVirtual.nombreCliente.vnat.net.
5. Botón de eliminar dominios: Elimina dominios que se han agregado.
6. Botón de agregar Location: Permite adicionar varios Locations que podrán ser configurados independientemente.
7. URI : URI del virtual host. Define la zona o carpeta del Virtual Host que deseamos personalizar.
   Para este ejemplo usaremos la raíz del sitio web "/".
   
8. Restricción de acceso: Podrá permitirse el acceso a una única red configurada en la pantalla de Máquinas y Redes del firewall.
   Para este ejemplo daremos acceso a cualquier máquina en Internet con la opción ANY.
   
9. Destino del virtual host: Se configura el destino del tráfico del Location.
   Puede ser un Redirect 301 o 302, o un servidor HTTP.
   Para mayor información ir a la sección Servidores HTTP.
   Para este ejemplo usaremos un servidor HTTP configurado con antelación llamado WORDPRESS.
   
10. Opción para activar el cache HTTP de Cloud-Bricks. Para este ejemplo lo dejaremos desactivado.
11. Botón de eliminar Locations: Es posible eliminar Locations creadas, esta tarea es irreversible.
    
12. Botón de Aceptar: Al darle clic se actualiza la lista de Virtual Hosts.
13. Botón Cancelar: Cancela las operaciones hechas.

Dar clic en el botón Aceptar y luego en Aplicar Cambios para guardar los cambios realizados. Ahora es posible accesar el web site utilizando cualquiera de los dominios configurados.

Restringir el acceso a una carpeta

Por cuestiones de seguridad, muchas veces es necesario restringir el acceso a una directorio o un URL del portal. Por ejemplo cuando se está creando una nueva sección de un portal la cual está en el URI /deportes podemos restringir el acceso para que sólo los desarrolladores puedan ingresar en ella. A continuación un ejemplo.

Se ha creado el portal web que responde en http://wordpress.pruebas.vnat.net/

Al ingresar al URL http://wordpress.pruebas.vnat.net/wordpress/ se muestra una instalación de Wordpress.

Ahora modificar el Virtual Host correspondiente para restringir el acceso al URL http://wordpress.pruebas.vnat.net/wordpress/ .

En el campo "Permitir" escoger la red que tendrá acceso exclusivo al URI de /wordpress, para este caso escoger la red GOOGLE_DNS_IPV4. Al ingresar de nuevo al URL http://wordpress.pruebas.vnat.net/wordpress/ el acceso está restringido.

Al ingresar al URL principal http://wordpress.pruebas.vnat.net/  el acceso sigue normal en el resto del site.

Redirects

Los redirect son un opción útil para controlar accesos a portales en desarrollo o en mantenimiento. Es posible redirigir el tráfico a sitios externos o servidores. Para agregar un redirect a un portal es necesario modificar el virtual Host configurado. Por ejemplo al ingresar a http://wordpress.pruebas.vnat.net/google el portal web arroja error 404.

Ahora modificar el Virtual Host correspondiente para incluir un redirect hacía el portal www.google.com

Al ingresar a http://wordpress.pruebas.vnat.net/google el portal se redirige a http://www.google.com
 

Un web site distribuido entre varios servidores HTTP

Es posible hacer que distintas zonas de un mismo web site sean atendidas por diferentes servidores HTTP.
A manera de ejemplo supongamos que queremos en nuestro web site, la URI /soporte sea atendida por un servidor HTTP específico.
Si tenemos una máquina virtual de soporte, se debe crear un servidor HTTP apuntando al puerto e IP de dicha máquina.

Dar clic en "Aceptar" y luego en "Aplicar cambios". Ahora alterando el Virtual Host es posible editar los locations y agregar la nueva URI, modificando la opción de "Destino" para apuntar al servidor HTTP que acabamos de crear.

De esta manera es posible crear distribuir los locations entre distintos servidores.

Crear reglas de reescritura de URIs

En la versión más reciente de la plataforma Cloud-Bricks, es posible usar el motor de reglas de NGINX para crear reglas de return y rewrite para poder controlar el comportamiento de sus web sites en situaciones particulares.
Se requiere conocimiento previo en Expresiones regulares para poder configurar este tipo de reglas. Se utiliza la sintaxis de Perl, sin embargo no son necesarias comillas (" , ') ni barras/slashes (/) para delimitar las expresiones.
Por favor consultar la documentación de NGINX para más información sobre casos de uso para esta herramienta.

1. Use este botón para agregar nuevas reglas.
   
2. Use este botón para agregar condiciones adicionales a una regla.
   
3. Menú de operadores de comparación: Seleccione el operador para comparar la variable de la izquierda con la expresión regular a la derecha.
• =   : Equals.  Verifica si el valor de la variable es idéntico al texto de la derecha.
  
• ~   : Match. Valida si el valor de la variable hace "match" con la expresión regular de la derecha. (Sensible a mayúsculas)
  
• ~*  : iMatch. Valida si el valor de la variable hace "match" con la expresión regular de la derecha. (Insensible a mayúsculas)
• != , !~ , !~* : Versiones negativas de los operadores anteriormente descritos.
  
4. Use este ícono para borrar una regla.
   
5. Menú de variables: Provee una lista de las variables que pueden usarse para crear condiciones. Es un subconjunto de la lista de variables de NGINX.
   
• host: Indica el nombre de host utilizado para la solicitud HTTP.
  
• http_cookie: Contiene las cookies enviadas por el cliente.
  
• http_user_agent: Identifica el tipo de cliente usado para la conexión.
  
• https:  Contiene el valor "on" si la conexión es segura. Vacío de lo contrario.
  
• is_mobile: Contiene el valor "1" si el cliente es un dispositivo móvil. 0 de lo contrario.
• is_bot: Contiene el valor "1" si el cliente es un bot o cliente no interactivo. 0 de lo contrario.
  
• is_desktop: Contiene "1" si el cliente actual utiliza un sistema operacional de escritorio. 0 de lo contrario.
• query_string: Contiene el texto después del "?" en una URL.
  
• request: Linea completa original del request.
  
• request_method: Método HTTP usado en la solicitud ("GET", "POST", "HEAD" , etc)
• request uri:  URI original completa (con argumentos).
• remote_addr:  Dirección IP del cliente o proxy que ejecutó la solicitud.
• remote_port: Puerto IP de origen utilizado por el cliente o proxy para ejecutar la solicitud.
  
• scheme: Protocolo del request, “http” o “https”
6. Use este ícono para eliminar condiciones de una regla.
   
7. Cuando se escriben reglas de rewrite, deben escribirse dos expresiones regulares.
   
1. Expresión regular "Match": Indica el patrón que la URI debe cumplir para aplicar la regla.
   
2. Expresión regular de reemplazo: Indica el patrón para modificar la URI si se cumple el patrón de "match".
   
8. Use este campo para escribir las expresiones regulares usadas para comparar las variables (5) con los operadores (3).
9. Menú de acciones: Aquí podrá seleccionar el tipo de acción a tomar si todas las condiciones se evalúan como verdaderas:
• return:  Responder la solicitud con un  código HTTP.
  
• rewrite_i: Redireccionamiento interno. Usar expresiones regulares para modificar la URI internamente sin enviar ninguna respuesta de redirect hacia el cliente. La URI será modificada antes de ser enviada hacia el servidor web de la máquina virtual correspondiente.
  
• rewrite_t : Usar expresiones regulares para alterar la URI actual enviando un código HTTP 302 hacia el cliente si la regla es aplicada.
• rewrite_p: Usar expresiones regulares para alterar la URI actual enviando un código HTTP 301 hacia el cliente si la regla es aplicada.
10. Campos para enviar códigos de respuesta HTTP en reglas return.
    
• Para códigos 3XX (redireccionamientos) se debe proveer una URL absoluta como destino.
  
• El código especial no estándar 444 se usa para cerrar la conexión actual sin enviar ninguna respuesta al cliente.
  
• Todos los demás códigos pueden enviar un texto adicional como respuesta al cliente.
  

Por favor no dude en contactar a nuestro equipo de soporte  si requiere ayuda en la configuración de este tipo de reglas.